This is currently 'ready' but the notification to update the image on update isn't firing 100% of the time. So sometimes, when I change a user image it just never changes even though it's been updated on the server. Happens about 50% of the time so I think I have an issue on my end to work out.

I've played around with this and I don't think that the issue is due to the notification being sent but a caching issue. If I edit the profile image for a different user then nothing will be properly updated for that user, even on the user sign in view. If I exit the admin user and then sign into the user I edited, then all of the images will appear properly.

Interesting. What is being done on the local user level to clear the cache on pfp update? I tried to mirror/reuse what I could but I could have missed something. Plus, I need to clean up this PR a bit it's a little hectic...

Daw, I merged it wrong...

This branch is broken but I needed to redo this anyway. I'm going to wipe and try again here off of Main later this week.

This should be good but I'm back to having the same issue as before where I'm unable to get images to refresh appropriately throughout. Going from no image -> image works appropriately but image -> new image doesn't always refresh. Is that image caching or did I screw up the notifications?

There is also a weird one where if you change your username from Server Users -> Server User Details it doesn't update for the settings. The reason for this is I'm not sure how to update the userSession.user.name.

Last item, I am using the UserID as the payload for didChangeUserProfile. If I change that to UserDto, that would be a bigger payload but it would also mean I can refresh the user once at update then use that across multiple ViewModels because I think right now there is a chance that like 2 refreshes for the same data can occur?

🎉 This should be the final Admin Dashboard PR until we update to 10.10 🎉

Ah! I probably should have googled that first haha... I've updated this to reflect what the names should be!

I was just briefly looking at Nuke. When we update a UserProfileImage, I added:

        .onNotification(.didChangeUserProfile) { notificationUser in
            if notificationUser == userId {
                let imageURL = source.url

                guard let imageURL else {
                    logger.info("No user profile image URL found")
                    return
                }

                let request = ImageRequest(url: imageURL)

                pipeline.cache[request] = nil
                pipeline.configuration.dataCache?.removeData(for: imageURL.absoluteString)
                logger.info("Image removed from cache: \(imageURL.absoluteString)")
            }
        }

The result of this is that ServerUsers profile images are appropriately getting cleared and replaced when the image updates! From my google, this looks right but let me know if this isn't the way to go!

This PR should be ready for a second look I think!

Debugging this a little bit further I see a larger issue: most images aren't cached at all in the expected directories. The only images that are cached as expected are the splash screens. For the rest of the images, the name generator that is used makes invalid filenames.

maxWidth is an issue since it would cause different keys for the same images just at different sizes. I'm pursuing a new caching system to help with that as well as hopefully some performance improvements, but I won't let that stop this.

Debugging this a little bit further I see a larger issue: most images aren't cached at all in the expected directories. The only images that are cached as expected are the splash screens. For the rest of the images, the name generator that is used makes invalid filenames.

Is that a Nuke issue or have I been using Nuke incorrectly? Is the .onNotification I did here the correct usage or will that need to change?

maxWidth is an issue since it would cause different keys for the same images just at different sizes. I'm pursuing a new caching system to help with that as well as hopefully some performance improvements, but I won't let that stop this.

I didn't even think about that for the URL maxWidth. Is there anything on my end that I can help with? Sorry, I feel like I've been creating a lot of additional work for you so please let me know if there is anything I can do to help out!

Nah, I've just been holding Nuke incompletely. The widths-causing-different keys has long been on my mind since I first implemented the caching but the lack-of-caching is new to me.

It's just that since now we need to manipulate the caches, the need for a better implementation is more pressing.

I have largely refactored our image caches to, well, work as expected. I've taken a lot of time to really understand our use case of images since on the server images are keyed by the item id, a tag, and image sizes which causes issues on our side for cache invalidation. The total implementation is not complete and I will be asking the creator of Nuke some clarifying questions to fit our use case a little bit more.

You should run through this really quick to check that the user images update as expected.

You should run through this really quick to check that the user images update as expected.

This works great! This is going to help a ton with #1345 as well! I only found 2 things. One was a comment that said 500mb when it was 1000mb and one was updating tvOS to use the new cache to get it to build.

Tested on both iOS and tvOS and everything is working as expected for the areas that we touched with this PR. All images update appropriately now on change, including the logged in user's image. Both locations have the same logic, but I have confirmed both editing your user from Settings > User and Settings > Dashboard > Users > User both work appropriately and are both reflected in both positions. That is, updating from one locations reflects everywhere it's used throughout Swiftfin. I think you nailed it with this change!

Tested tvOS as well. We don't have any logic there to update user images, nor should we IMO so there is less to change. That being said, the images are where they are expected to be and there are no weird caching side effects that I can see!

The only thing that's a little weird (and this was weird before your changes) is that the caching behaves weirdly on the UserSignInView. If I switch to a new server, it uses the images from the previously selected server:

This is behaving in the same way as before this PR so I don't think we need to fix it for this PR. Just something where, if you knew what was causing this on the caching side, might be nice to make a quick swap on. Otherwise, if we need to do. some digging, I can do that later on another PR!

Thank you for those fixes and testing that. It looks like we'll have to stick an id somewhere on that view.